Product Code Database
International email arises from the combined provision of internationalized domain names ( IDN)Started with: and email address internationalization ( EAI).Started with: The result is email that contains international characters (characters which do not exist in the ASCII character set), encoded as UTF-8, in the email header and in supporting mail transfer protocols. The most significant aspect of this is the allowance of email addresses (also known as email identities) in most of the world's writing systems, at both interface and transport levels.
The following are valid traditional email addresses:
stellyamburrr985@example.com (English, ASCII)
Abc.123@example.com (English, ASCII)
user+mailbox/department=shipping@example.com (English, ASCII)
!#$%&'*+-/=?^_`.{|}~@example.com (English, ASCII)
"Abc@def"@example.com (English, ASCII)
"Fred\ Bloggs"@example.com (English, ASCII)
"Joe.\\Blow"@example.com (English, ASCII)
A cyrillic languaged people might wish to use i.e. бацка.махно as their identifier but be forced to use a transcription such as batska.makno@example.org or even some other completely unrelated identifier instead. The same is true of Chinese, Japanese, and other nationalities that do not use , but also applies to users from non-English-speaking European countries whose desired addresses might contain (e.g. André or Płużyna). As a result, email users are forced to identify themselves using non-native scripts, which may result in errors due to ambiguity of transliteration (for example, иван.сергеев may become ivan.sergeev, ivan.sergeyev, or something else). Alternatively, developers of email systems must compensate for this by converting identifiers from their native scripts to ASCII scripts and back again at the user interface layer.
International email, by contrast, uses Unicode characters encoded as UTF-8—allowing for the encoding the text of addresses in most of the world's writing systems.RFC 6530: Overview and Framework for Internationalized Email
The following are all valid international :
([[Chinese|Chinese language]], [[Unicode]])
ಬೆಂಬಲ@ಡೇಟಾಮೇಲ್.ಭಾರತ ([[Kannada]], Unicode)
अजय@डाटा.भारत ([[Hindi|Hindi language]], Unicode)
квіточка@пошта.укр (Ukrainian, Unicode)
χρήστης@παράδειγμα.ελ ([[Greek|Greek language]], Unicode)
Dörte@Sörensen.example.com ([[German|German language]], Unicode)
коля@пример.рф ([[Russian|Russian language]], Unicode)
مثال@موقع.عر ([[Arabic|Arabic script]], Unicode)
The 2012 standards RFC 6532 and RFC 6531 allow the inclusion of Unicode characters in a header content using UTF-8 encoding, and their transmission via SMTP—but in practice support is only slowly rolling out.
Since traditional email standards constrain all email header values to ASCII only characters, it is possible that the presence of UTF-8 characters in email headers decreases the stability and reliability of transporting such email. This is because some email servers do not support these characters. Checking compliance with UTF-8 strings must be done software package by software package (see #Adoption below.) There was an experimental method proposed by the IETF, by which email could be somehow downgraded into the legacy all-ASCII format which all standard email servers support. This proposal was deemed too cumbersome; the meaning of the left hand side part of an email address is local to the target server, and so there is no way to check whether xn--''something'' is a valid user name, used in some domain. It was later obsoleted in 2012.
Unicode also has recommended Email Security Profiles for Identifiers.
The ICANN-sponsored Universal Acceptance Working Group is working make EAI accepted in more places and publishes annual reports on acceptance.
Standards framework
The set of Internet RFC documents RFC 6530, RFC 6531, RFC 6532, and RFC 6533, all of them published in February 2012, define mechanisms and protocol extensions needed to fully support internationalized email addresses. These changes include an SMTP extension and extension of email header syntax to accommodate UTF-8 data. The document set also includes discussion of key assumptions and issues in deploying fully internationalized email.
Adoption
See also
Bibliography
External links
|
|
